Monitoring users of a computer network

ABSTRACT

Communicating with and/or monitoring of a targeted used in computer-network environment (e.g., an instant messaging system) involves detecting that the targeted user has signed on to the network, and upon detecting the signon, automatically communicating with the targeted user, for example, by sending an instant message previously specified by a targeting user. Alternatively, or in addition, the targeting user can receive notification that the targeted user has signed on and/or that the instant message has been sent. Instead of, or in addition to, automatically sending an instant message and/or notifying the targeting user, a predefined operation specified by the targeting user (e.g., operating system command, script or executable file) can be performed. These various operations can be performed on one or more client systems, on one or more server systems, or any combination thereof.

TECHNICAL FIELD

[0001] This application relates to monitoring users of a computernetwork, for example, to facilitate messaging between users in an onlinecomputer services environment.

BACKGROUND

[0002] The computer system 100 illustrated in FIG. 1 represents atypical hardware setup for executing software that allows a user toperform tasks such as communicating with other computer users, accessingvarious computer resources, and viewing, creating, or otherwisemanipulating electronic content—that is, any combination of text,images, movies, music or other sounds, animations, 3D virtual worlds,and links to other objects. The system includes various input/output(I/O) devices (mouse 103, keyboard 105, display 107) and a generalpurpose computer 100 having a central processor unit (CPU) 121, an I/Ounit 117 and a memory 109 that stores data and various programs such asan operating system 111, and one or more application programs 113. Thecomputer system 100 also typically includes some sort of communicationscard or device 123 (e.g., a modem or network adapter) for exchangingdata with a network 127 via a communications link 125 (e.g., a telephoneline).

[0003] As shown in FIG. 2, a user of a computer system can accesselectronic content or other resources either stored locally at theuser's own client system 202 (for example, a personal or laptopcomputer) or remotely at one or more server systems 200. An example of aserver system is a host computer that provides subscribers with onlinecomputer services such as e-mail, e-commerce, chat rooms, Internetaccess, electronic newspapers and magazines, etc.

[0004] Users of a host computer's online services typically communicatewith one or more central server systems 200 through client softwareexecuting on their respective client systems 202. In practice, a serversystem 200 typically will not be a single monolithic entity but ratherwill be a network of interconnected server computers, possiblyphysically dispersed from each other, each dedicated to its own set ofduties and/or to a particular geographical region. In such a case, theindividual servers are interconnected by a network of communicationlinks, in known fashion. One such server system is “America Online 4.0”from America Online, Incorporated of Virginia also known as “AOL”).

[0005] One increasingly popular computer network-based activity isreferred to as “instant messaging.” An instant message is a form ofelectronic communication between users of a computer network in which awindow pops-up on the recipient's computer screen “instantly” andwithout the recipient's having to access an e-mail program or otherwisecheck for messages. An instant message appears essentially as soon asthe message sender clicks the send button subject to any time orpropagation delays the message may have encountered on the network. Incomparison to most e-mail applications, instant messaging enables usersto communicate with each other in a more dynamic, urgent and interactivemanner.

[0006]FIG. 3 is a screen shot of an Instant Message (IM) window 30 asused in AOL's Instant Messenger (“AIM”) system. As shown therein, thewindow 30 includes a text display area 31 and text entry area 32. Bothusers involved in the IM under consideration (i.e., sender andrecipient) would have a similar window displayed on his or her computermonitor. When one user (PhillipsJC) types a comment 34 in text entryarea 32 and clicks the Send button 33 (or, depending on theconfiguration, presses the “ENTER” key on the keyboard), the enteredtext (e.g., “Hey, did you see the game last night?”) is displayed in thetext display area 31 of the window 30 such that it is visible to bothusers. After FRsnafu enters a comment 35 in response and clicks the Sendbutton 33, that comment 35 appears in the text display area 31underneath the previous comment 34. This exchange of comments continuesindefinitely until the users decide to terminate the exchange.

[0007] Typically, instant messages can be sent-to another user only whenthat user is presently signed on to the computer service. Users who aresigned off are unavailable to receive instant messages. Accordingly,another popular innovation introduced by America Online is the “BuddyList,” which allows users to monitor when other specified users(“buddies”) are signed onto and/or off of the computer service underconsideration (e.g., AOL Instant Messenger).

[0008] As shown in FIG. 4, the Buddy List is implemented as a window 40that lists specified users, or buddies, who are signed on to the AIMsystem. In the example shown, the Buddy List for user “PhillipsJC”indicates that four of PhillipsJC's buddies 41-44 currently are signedon to the system and thus available to receive instant messages. TheBuddy List is updated based on information received from a server to addor delete names of buddies as they sign on and off, respectively. SuchBuddy List updates can be accompanied by various audible and visualindications to help notify the user that a buddy has signed on or off.

[0009] Despite the various notification mechanisms, a user neverthelessmay fail to notice that a buddy with whom IM communication is desiredhas signed on to the system. For example, if the user is on thetelephone or away from his or her office, one of that user's buddies maysign on and then off again unnoticed by the user. Alternatively, or inaddition, even when a user notices that a buddy has signed on to thesystem, the user nevertheless may be unable to send the buddy an IMbecause the user may be otherwise engaged (e.g., in a meeting).

[0010] Other reasons exist why a user might not notice that a buddy hassigned on and/or miss an opportunity to send an IM to the buddy. Forexample, the user might have so many buddies on his buddy list that theycannot all fit on the display screen, or in a display window., at thesame time. Moreover, the buddy list window might be obscured by otherwindows or objects and thus the user might not be able to notice whenthe buddy has signed on. In any of these and possibly other situations,the buddy may sign off of the system before the user is able to send anIM, thus missing the window of opportunity.

[0011] Accordingly, the present inventor recognized that it would bedesirable to provide users with mechanisms for monitoring signons bybuddies and/or communicating with the buddies immediately andautomatically upon their signing on to the system.

SUMMARY

[0012] Implementations may include various combinations of the followingfeatures.

[0013] In one aspect, a computer-implemented method of communicatingwith a user includes detecting that a previously unavailable user isavailable to receive messages, and automatically sending a predeterminedmessage (e.g., an instant message) to the user upon detecting that theuser has become available. Alternatively, or in addition, notificationmay be provided to a monitoring user that the previously unavailableuser has become available and/or that the predetermined message wassent. The method may further include instantiating an instant messaging,window on a computer screen of the monitoring user upon detecting thatthe previously unavailable user has become available. Optionally, thenotified monitoring user may have previously specified the predeterminedmessage. Moreover, a command specified by the monitoring user (e.g., anoperating system command, a script, or an executable file) may beexecuted upon detecting the user's availability.

[0014] Prior to the detection, a request may have been received from themonitoring user to monitor availability of the previously unavailableuser. The received request may be queued until the previouslyunavailable user becomes available. The automatic sending of thepredetermined message may include instantiating a window on the user'scomputer screen displaying the predetermined message. The operations ofdetecting and the automatic message sending may be repeated each timethe user newly becomes available. Moreover, the detecting and automaticmessage sending operations may be performed entirely on one or moreserver systems, entirely on one or more client systems, or in adistributed manner among one or more server systems and one or moreclient systems.

[0015] In another aspect, a computer-implemented instant messagingmethod may include detecting that a targeted user has signed on to aninstant messaging service, and upon detecting the signon, automaticallysending to the targeted user an instant message previously specified bya targeting user. The targeting user can receive notification that thetargeted user has signed on to the instant messaging service and/or thatthe instant message was sent.

[0016] Automatically sending the instant message may includeinstantiating a window on the targeted user's computer screen displayingthe instant message and/or instantiating an instant messaging window ona computer screen of the targeting user upon detecting that the targeteduser has signed on.

[0017] Prior to detection, a request may be received from the targetinguser to monitor a signon by the targeted user. The received request maybe queued until the targeted user signs on. The targeting user also mayprovide input specifying the instant message.

[0018] In another aspect, a computer-implemented method of monitoringusers of a computer network may include receiving from a monitoring usera request to monitor availability of a monitored user, detecting thatthe monitored user is available (e.g., has signed on), and automaticallyperforming a predefined operation specified by the monitoring user(e.g., send an instant message, provide notification to the monitoringuser or another entity, or both, and/or execute an operating systemcommand, a script, or an executable file) upon detecting that themonitored user is available.

[0019] In another aspect, a computer-implemented method, performed at aserver, of communicating with a user on a computer network including aplurality of clients and at least one server, may include receiving arequest to detect when a currently unavailable user becomes available toreceive messages, detecting that the user has become available, andautomatically sending a predetermined message to the user upon detectingthat the user has become available.

[0020] In another aspect, a computer-implemented method, performed at aclient, of communicating with a user on a computer network including aplurality of clients and at least one server, may include generating arequest to detect when a currently unavailable user becomes available toreceive messages, receiving notice that the user has become available,and automatically sending a predetermined message to the user.

[0021] In another aspect, an instant messaging system may include aserver system and one or more client systems, each associated with acorresponding user, in communication with the server system. The serversystem may include software instructions for (i) monitoring a targeteduser's availability to receive instant messages, and (ii) sending anotification that a targeted user has become available to receiveinstant messages. Each of the one or more client systems may includesoftware instructions for (i) queuing a request to send an instantmessage to a currently unavailable targeted user, and (ii) sending theinstant message to the targeted user upon receiving notification fromthe server system that the targeted user has become available to receiveinstant messages.

[0022] One or more of the following advantages may be provided. Thetechniques and methods described here enable users to more reliably andefficiently track the comings and goings of their buddies. As a result,the likelihood of a user's being able to communicate (e.g., by instantmessage) with buddies, even those who sign on to the computer serviceinfrequently or sporadically, is enhanced dramatically.

[0023] In addition, communication between users is improved by providingmechanisms to automatically and instantly communicate with buddies upontheir signing on to the computer service. The sending user needs neitherto be aware of the buddy's signing on, nor be available to send an IM,for this automatic and instant communication to occur. Rather, thesending user needs only to set up the “pounce” and the buddy at whom thepounce is targeted can receive an IM automatically and without requiringthe sending user's further attention or authorization.

[0024] The details of one or more embodiments are set forth in theaccompanying drawings and the description below. Other features,objects, and advantages of the invention will be apparent from thedescription and drawings, and from the claims.

DRAWING DESCRIPTIONS

[0025]FIG. 1 is a block diagram of a computer system.

[0026]FIG. 2 shows a typical network computing environment.

[0027]FIG. 3 is a screen shot of an “Instant Message” window.

[0028]FIG. 4 is a screen shot of a “Buddy List” window in AOL's InstantMessenger for Windows.

[0029]FIG. 5 is a flowchart of pouncing on a user.

[0030]FIG. 6 is a screen shot of a “Buddy List” window in AOL InstantMessenger for Unix.

[0031]FIG. 7 is a screen shot of a “Tools” pull-down menu in the BuddyList window of FIG. 6.

[0032]FIG. 8 is a screen shot of a “Create New Pounce” window.

[0033]FIG. 9 is a screen shot of an instant message window correspondingto the Create New Pounce window of FIG. 8.

[0034]FIG. 10 is screen shot of a “Conversation” window.

[0035]FIG. 11 is a screen shot of a “Send IM” window.

[0036]FIG. 12 is another screen shot of a “Tools” pull-down menu in theBuddy List window of FIG. 6.

[0037]FIG. 13 is a screen shot of an “Edit Pounce” window.

[0038] Like reference numbers and designations in the various drawingsindicate like elements.

DETAILED DESCRIPTION

[0039]FIG. 5 is a flowchart of a process that allows one user to“pounce” on another user (e.g., a buddy) as soon as the buddy signs onto the computer service. “Pounce” refers to the ability to take one ormore specified actions (e.g., send a message, emit an audible or visualnotification, execute a command, etc.) automatically upon determiningthat a specified event has occurred, for example, detecting that a buddyhas signed on to the computer service.

[0040] As shown in FIG. 5, as an initial step in pouncing on anotheruser (the “pouncee” or “targeted user”), a first user (the “pouncer” or“targeting user”) sets up the parameters of the pounce (step 50).Although these parameters can vary between implementations, typicalparameters that could be specified by the pouncer include the identityof the pouncee (specified by, e.g., signon ID, name, e-mail address,etc.); the event that triggers the, pounce (e.g., pouncee's signing onto system, pouncee's sending an IM to a specified party, detection ofbeing added to or deleted from the pouncee's buddy list, etc.); theaction or actions that are to be taken (e.g., send an IM; send a chatinvitation, audible or visual notification, execute a specified command,or any other arbitrary action); and whether the pounce should occur onlyonce or upon each separate detection of the specified trigger event. Thepouncee designated in step 50 can, but need not necessarily, be on thepouncer's Buddy List.

[0041] After being set-Up by the pouncer, the pounce is queued pendingoccurrence of the specified event (step 51). In effect, an indication isset at the server that the pouncer's client application is to benotified upon detection of the specified event. The queue can bemaintained either locally at the pouncer's client system or remotely ata server system. Either a single pounce or multiple pounces can be inthe queue concurrently. In addition, a pounce can be either asingle-shot (i.e., executed only once on the first occurrence of thespecified event) or persistent (i.e., executed with each occurrence ofthe specified event).

[0042] The next step is to wait for occurrence of the specified event(step 52), for example, a detection that a specified user has signed onto the computer service. This detection can occur either at the clientsystem or in conjunction with a server on the network.

[0043] Next, upon occurrence of the specified event, the pounce isexecuted (step 53). Execution of the pounce can occur at the pouncer'sclient system or at the pouncee's client system, or both, potentially inconjunction with one or more server systems. The particular actions thatcan be taken upon execution of the pounce can vary with differentimplementations, and/or based on user-specified preferences. Typicalactions may include one or more of the following: sounding an alarm(step 54); sending an IM (step 55), opening a conversation window on thepouncer's client system (step 56); or executing a user-specified command(step 57), for example, locally on the pouncer's client system. Asindicated by dotted lines, each of the actions indicated in steps 54-57is optional. Moreover, other actions beyond or in addition to thoseshown in steps 54-57 may be taken.

[0044] After the pounce has been executed, it is determined whether ornot the pounce is persistent—that is, whether or not the pounce shouldbe executed only once or each time upon detection of the specified event(step 58). If the pounce is persistent, it remains in the queue and theprocess returns to step 52 to wait for the next specified event. On theother hand, if the pounce is a single-shot, the pounce is removed fromthe queue (step 59) and the process returns to step 50 to allow thepouncer to set up another pounce, as desired.

[0045] A single user can have multiple pounces pending at the same time.The process shown in FIG. 5 generally represents steps that are takenfor each individual pounce sequence.

[0046] FIGS. 6-13 are screen shots illustrating an implementation of thepounce concept in a Unix-based version of the AIM application (referredto as “TiK”). FIG. 6 shows a TiK Buddy List window 60 for user “FRsnafu”displaying a list 61 of three of FRsnafu's buddies 62 currently signedon to the AIM system. The Buddy List window 60 also includes a menu bar67 listing three drop-down menus (File, Tools, Help), a text area 66 forentering text strings for web searches, an IM button 63 forinstantiating an IM window to send an IM to another user, an Info button64 for retrieving information about another user, and a Chat button 65for instantiating a Chat window to invite another user to participate ina chat session.

[0047] As noted above, the Buddy List window 60 in FIG. 6 indicates thatthree of FRsnafu's buddies 62 currently are signed on to AIM. However,in this example, user FRsnafu desires to send an IM to another buddy,“PhillipsJC,” who is not currently signed on to the AIM system.Accordingly, FRsnafu, the pouncer in this example, decides to set up apounce to receive notification, and to send PhillipsJC an IM, as soon asPhillipsJC signs on to AIM.

[0048]FIG. 7 is a screen shot of the Tools drop-down menu 70, which thepouncer accesses to set up a pounce. As shown therein, the pouncerselects menu option “Buddy Pounce” 72, which in turn brings up asub-menu displaying a single option 73, “New Pounce,” that enables thepouncer to set up the desired pounce.

[0049]FIG. 8 shows a “Create New Pounce” window 80 which is displayed onthe pouncer's screen in response to selection of the “New Pounce” option73. As shown in FIG. 8, the Create New Pounce window 80 includes a namefield 81 into which the pouncer enters the name of the pouncee i.e., thebuddy who is the subject of the pounce. The window 80 also includes fivecheck-boxes 82-86 that the pouncer can check or not to selectivelyactivate five corresponding features.

[0050] If the pouncer checks box 82, a blank IM window 110 (FIG. 11)will pop up on the pouncer's screen when the pouncee signs on to the AIMsystem. Under this option, an IM is not sent automatically to thepouncee, but rather the IM interface window is merely instantiated toallow the pouncer to easily and quickly enter appropriate text and sendan IM to the pouncee.

[0051] In contrast, if the pouncer checks box 83 in window 80 (FIG. 8),an IM will be sent to the pouncee automatically, and will pop up on thepouncee's screen, as soon as the pouncee signs on to AIM. This automaticsending of an IM is performed transparently as a consequence of the AIMsystem detecting the specified event (i.e., the pouncee's signing on)and without any input or response on the part of the pouncer beyondinitially setting up the pounce. The particular text to be included inthe IM sent to the pouncee—“Gotcha!”—is specified by the pouncer inmessage field 87.

[0052]FIG. 9 is a screen shot of the Instant Message window 90 that popsup on the pouncee's window upon signing on to AIM. As shown, the window90 includes a text display area 93 showing the identity 91 of the IMsender (i.e., the pouncer) and the message 92 (“Gotcha!”) specified bythe pouncer.

[0053] When the pouncer designates by checking box 83 (FIG. 8) that anIM should sent to the pouncee automatically, the Tik application alsoautomatically instantiates a “Conversation” window 102 on the pouncer'sclient system, as shown in FIG. 10. Essentially, the Conversation window102 fulfills the same function as the Instant Message window 30 shown inFIG. 3. Specifically, the Conversation window 102 includes a textdisplay area 112, a text entry area 116, and buttons 118 to allow theuser to control various aspects of the IM presentation and exchange. Asshown in FIG. 10, the text display area 112 in window 102 includes asingle line of text corresponding to the IM automatically sent to thepouncee upon execution of the pounce. This single line includes a timefield 104 showing the time at which the IM was sent, a name field 106showing the IM sender's identity, and a message field 108 showing themessage.

[0054] Checking box 84 in window 80 (FIG. 8) causes a “Pounce Sound”(i.e., an audible notification) to be played on the pouncer's clientsystem upon execution of the pounce. The Pounce Sound notifies thepouncer that the pouncee has signed on to the AIM system.

[0055] Box 85 in window 80 determines whether the pounce should be asingle-shot or persistent. In the example shown, box 85 is unchecked sothe pounce being set up in FIG. 8 will be persistent—that is, it willexecute with each detection of a signon by the pouncee. In contrast, ifbox 85 was checked, the pounce would execute only once upon nextdetecting a signon by the pouncee and then would be deleted from thepounce queue.

[0056] By checking box 86 in window 80 (FIG. 8), the pouncer can specifya command (for example, a operating system command, a script, or anexecutable file) that is to be executed as part of the pounce execution.The particular command to be executed—in this example, an executablefile at the path “c:\notify.exe”—is specified by the pouncer in textentry area 88 and can be virtually any command that is executable by thepouncer's client system. For example, the notify.exe command could sendan IM to one or more third parties informing them that the pouncee hassigned on. Alternatively, or in addition, notify.exe could launchanother application (e.g., an online computer game to play with thepouncee) or initiate virtually any other arbitrarily-complex orarbitrarily-simple computer-controlled operation.

[0057] When the pouncer has set up the new pounce with the desiredparameters, the pouncer clicks button 89 (FIG. 8) and the pounce is thensaved in the queue of currently pending pounces.

[0058] As noted above, a single user can have more than one pouncepending in the queue at the same time. FIG. 12, for example, shows aBuddy List sub-menu 120 for a pouncer who has three pounces 122, 124 and126 concurrently queued up and pending. Each of these pounces. 122, 124,126 is individually configurable as described above with regard to FIG.8.

[0059] Moreover, a queued pounce can be modified as desired by selectingit from the sub-menu 120, which in turn brings up an “Edit Pounce”window 130 as shown in FIG. 13. The Edit Pounce window 130 essentiallyis the same as the Create New Pounce window 80 shown in FIG. 8, exceptthat the Edit Pounce window 130 is presented to the pouncer with thedata fields and check boxes selectively filled in according to thepounce's current parameter set. The pouncer can modify any of theseparameters by checking or unchecking boxes 132-136, and/or changing thetext in fields 137-139. Once the pounce's parameters have been modifiedas desired, the pouncer can save the modified pounce in the queue byclicking the OK button 141. Alternatively, the pouncer can delete thepounce from the queue by clicking the Delete button 140.

[0060] The techniques, methods and systems described here may findapplicability in any computing or processing environment in whichmonitoring other users and/or communicating with them is desirable. Inparticular, the concept of pouncing on another user could be applied toother media such as internet TV, cellular telephones, pagers, two-wayradios, etc. For example, a cellular telephone service provider couldimplement a system in which a queued-up telephone call was completed assoon as the intended recipient turned on his or her cell phone.

[0061] Various implementations of the systems and techniques describedhere may be realized in digital electronic circuitry, or in computerhardware, firmware, software, or in combinations thereof. A system orother apparatus that uses one or more of the techniques and methodsdescribed here may be implemented as a computer-readable storage medium,configured with a computer program, where the storage medium soconfigured causes a computer system to operate on input and/or generateoutput in a specific and predefined manner. Such a computer system mayinclude one or more programmable processors that receive data andinstructions from, and transmit data and instructions to, a data storagesystem, and suitable input and output devices.

[0062] Each computer program may be implemented in a high-levelprocedural or object-oriented programming language, or in assembly ormachine language if desired; and in any case, the language may be acompiled or interpreted language. Suitable processors include, by way ofexample, both general and special purpose microprocessors.

[0063] Generally, a processor will receive instructions and data from aread-only memory and/or a random access memory. Storage devices suitablefor tangibly embodying computer program instructions and data includeall forms of nonvolatile memory, including semiconductor memory devices,such as EPROM, EEPROM, and flash memory devices; magnetic disks such asinternal hard disks and removable disks; magneto-optical disks; andCD-ROM disks.

[0064] Any of the foregoing may be supplemented by, or implemented in,specially-designed ASICs (application-specific integrated circuits).

[0065] A number of embodiments have been described. Nevertheless, itwill be understood that various modifications may be made withoutdeparting from the spirit and scope of the invention. Accordingly, otherembodiments are within the scope of the following claims.

What is claimed is:
 1. A computer-implemented method of communicatingwith a user, the method comprising: detecting that a previouslyunavailable user is available to receive messages; and automaticallysending a predetermined message to the user upon detecting that the userhas become available.
 2. The method of claim 1 further comprisingproviding notification to a monitoring user that the previouslyunavailable user has become available.
 3. The method of claim 2 whereinthe notified monitoring user previously specified the predeterminedmessage.
 4. The method of claim 1 further comprising providingnotification to a monitoring user that the predetermined message wassent.
 5. The method of claim 4 wherein the notified monitoring userpreviously specified the predetermined message.
 6. The method of claim 1wherein the predetermined message comprises an instant message.
 7. Themethod of claim 1 wherein the predetermined message comprises contentspecified by a monitoring user seeking to communicate with thepreviously unavailable user.
 8. The method of claim 1 whereinautomatically sending the predetermined message comprises instantiatinga window on the user's computer screen displaying the predeterminedmessage.
 9. The method of claim 1 further comprising, prior to thedetection, receiving a request from a monitoring user to monitoravailability of the previously unavailable user.
 10. The method of claim9 further comprising queuing the received request until the previouslyunavailable user becomes available.
 11. The method of claim 9 furthercomprising receiving input from the monitoring user specifying thepredetermined message.
 12. The method of claim 9 further comprisinginstantiating an instant messaging window on a computer screen of themonitoring user upon detecting that the previously unavailable user hasbecome available.
 13. The method of claim 9 further comprising executinga command specified by the monitoring user.
 14. The method of claim 13wherein the command comprises one or more of an operating systemcommand, a script, or an executable file.
 15. The method of claim 1further comprising repeating the detecting and the automatic messagesending each time the user newly becomes available.
 16. The method ofclaim 1 wherein the detecting and the automatic message sending areperformed entirely on one or more server systems.
 17. The method ofclaim 1 wherein the detecting and the automatic message sending areperformed entirely on one or more client systems.
 18. The method ofclaim 1 wherein the detecting and the automatic message sending aredistributed among one or more server systems and one or more clientsystems.
 19. A computer-implemented instant messaging method comprising:detecting that a targeted user has signed on to an instant messagingservice; and upon detecting the signon, automatically sending to thetargeted user an instant message previously specified by a targetinguser.
 20. The method of claim 19 further comprising providingnotification to the targeting user that the targeted user has signed onto the instant messaging service.
 21. The method of claim 19 furthercomprising providing notification to the targeting user that the instantmessage was sent.
 22. The method of claim 19 wherein automaticallysending the instant message comprises instantiating a window on thetargeted user's computer screen displaying the instant message.
 23. Themethod of claim 19 further comprising, prior to the detection, receivinga request from the targeting user to monitor a signon by the targeteduser.
 24. The method of claim 23 further comprising queuing the receivedrequest until the targeted user signs on.
 25. The method of claim 23further comprising receiving input from the targeting user specifyingthe instant message.
 26. The method of claim 23 further comprisinginstantiating an instant messaging window on a computer screen of thetargeting user upon detecting that the targeted user has signed on. 27.The method of claim 23 further comprising executing a command specifiedby the targeting user.
 28. The method of claim 27 wherein the commandcomprises one or more of an operating system command, a script, or anexecutable file.
 29. The method of claim 19 further comprising repeatingthe detecting and the automatic instant message sending each time thetargeting user signs on.
 30. The method of claim 19 wherein thedetecting and the automatic instant message sending are performedentirely on one or more server systems.
 31. The method of claim 19wherein the detecting and the automatic instant message sending areperformed entirely on one or more client systems.
 32. The method ofclaim 19 wherein the detecting and the automatic instant message sendingare distributed among one or more server systems and one or more clientsystems.
 33. A computer-implemented method of monitoring users of acomputer network, the method comprising: receiving from a monitoringuser a request to monitor availability of a monitored user; detectingthat the monitored user is available; and automatically performing apredefined operation specified by the monitoring user upon detectingthat the monitored user is available.
 34. The method of claim 33 whereinperforming the predefined operation comprises sending an instant messageto the monitored user.
 35. The method of claim 33 wherein performing thepredefined operation comprises executing an operating system command, ascript, or an executable file specified by the monitoring user.
 36. Themethod of claim 33 wherein performing the predefined operation comprisesproviding a notification that the monitoring user is available.
 37. Themethod of claim 36 wherein the notification is provided to themonitoring user.
 38. The method of claim 36 wherein the notification isprovided to an entity other than the monitoring user.
 39. The method ofclaim 33 wherein the receiving, detecting and automatically performing apredefined operation are performed entirely on one or more serversystems.
 40. The method of claim 33 wherein the receiving, detecting andautomatically performing a predefined operation are performed entirelyon one or more client systems.
 41. The method of claim 33 wherein thereceiving, detecting and automatically performing a predefined operationare distributed among one or more server systems and one or more clientsystems.
 42. A computer-implemented method of communicating with a useron a computer network comprising a plurality of clients and at least oneserver, the method comprising at the server: receiving a request todetect when a currently unavailable user becomes available to receivemessages; detecting that the user has become available; andautomatically sending a predetermined message to the user upon detectingthat the user has become available.
 43. A computer-implemented method ofcommunicating with a user on a computer network comprising a pluralityof clients and at least one server, the method comprising at a client:generating a request to detect when a currently unavailable user becomesavailable to receive messages; receiving notice that the user has becomeavailable; and automatically sending a predetermined message to theuser.
 44. An instant messaging system comprising: a server systemcomprising software instructions for (i) monitoring a targeted user'savailability to receive instant messages, and (ii) sending anotification that a targeted user has become available to receiveinstant messages; and one or more client systems in communication withthe server system, each client system being associated with a targetinguser and comprising software instructions for (i) queuing a request tosend an instant message to a currently unavailable targeted user, and(ii) sending the instant message to the targeted user upon receivingnotification from the server system that the targeted user has becomeavailable to receive instant messages.
 45. Computer software, tangiblyembodied on a computer-readable medium or in a propagated carriersignal, for communicating with a user of an instant messaging system,the software comprising instructions to cause a computer system toperform the following operations: (a) detect that a previouslyunavailable user has become available to receive instant messages; and(b) automatically send a predetermined instant message to the user upondetecting that the user has become available.
 46. The computer softwareof claim 45 wherein the software to perform operations (a) and (b)resides entirely on one or more server systems.
 47. The computersoftware of claim 45 wherein the software to perform operations (a) and(b) resides entirely on one or more client systems.
 48. The computersoftware of claim 45 wherein the software to perform operations (a) and(b) is distributed among one or more server systems and one or moreclient systems.